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an attempt to modify the contents of the one or more system 
volumes, the NC client causes information identifying the 
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the one or more system volumes in a storage area associated 
with the NC client. 
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PROVIDING A RELIABLE OPERATING FIG. 1 is a simplified block diagram that conceptually 

SYSTEM FOR CLIENTS OF A NET-BOOTED illustrates a network computer system according to one 

ENVIRONMENT embodiment of the present invention. 

FIG. 2 is a block diagram of a digital processing system 
5 which may be used in accordance with one embodiment of 
BACKGROUND OF THE INVENTION lhe pTCSe ^ { invention. 

1. Field of the Invention FIG. 3 is a flow diagram illustrating processing that 
The invention relates generally to network computing. occurs on an NC client ^ an NC server 10 accomplish a 

More particularly, the invention relates to the provision, 10 net-boot of the NC client according to one embodiment of 

administration, and maintenance of an operating system in a tne present invention. 

net-booted environment. FIG. 4 is a flow diagram illustrating how NC client write 

2. Description of the Related Art requests directed to the system volume are handled accord- 

, . ill i ing to one embodiment of the present invention. 

Most organizations currently employ local area networks & y 

(LANs) of thick clients, e.g., personal computers. While this is FIG - 5 is a flow diagram illustrating how NC client read 
represents an improvement over the disconnected comput- requests directed to the system volume are handled accord- 
ing environments of a decade earlier, many limitations still t0 one embodiment of the present invention, 
exist. In current LAN environments, each client computer FIG. 6 is a simplified block diagram illustrating an 
has its own local copy of operating system software, appli- exemplary hierarchical directory structure that may be used 
cation programs, and user customizations to the desktop 20 by an NC server according to one embodiment of the present 
environment. Typically there is no centralized mechanism invention. 

for maintaining a consistent system configuration in such a FIG. 7 is a flow diagram illustrating NC system admin- 
computing environment. Consequently, individual user istration processing according to one embodiment of the 
workstations often get out-of-sync with each other as one or present invention. 

more users upgrade to newer versions of the operating 25 FIG. 8 is a simplified block diagram illustrating two NC 

system, upgrade their application programs, or install appli- systems coupled via the Internet. 

cation programs that were not part of the original system F IG. 9 is a block diagram that conceptually illustrates NC 

configuration. Additionally, m this type of uncontrolled, clieQt interaclion ^ a s lit0S according to one embodi- 

decentrahzed environment, the operatmg system of a chent meQt of the m ^^on. 

computer can easily become corrupted. This is especially 30 

true with the Microsoft <§> Windows ® 95, 98 and NT FIG ' 10 » a bl ° C * : dw « ram that «™*P*^ grates the 

operating systems where user modification of a single sys- S ™ e ° f f \ f u adow S * S ! era ™ lume accordm * t0 one 

tern file can have undesirable consequences and require embodimeilt of the P resent ™ entl0n - 

significant downtime. For example, editing the Windows FIG - n 15 a block diagram that conceptually illustrates the 

Registry file could render a client computer unusable 35 structure of a shadow system volume according to another 

thereby requiring reinstallation of the computer's operating embodiment of the present invention in which a banding 

system software and all the application programs. feature is employed. 

In view of the foregoing, it should be apparent that FIG. 12 is an example of a machine-readable medium that 

administration and maintenance of current computing envi- accessed by a digital processing system such as an 

ronments is complex and time consuming. Therefore, what 40 * C chent or aD NC according to one embodiment of 

is needed is a reliable computing environment that can be the P resent inventlon - 

maintained more easily and at a lower cost. DETAILED DESCRIPTION OF THE 



BRIEF SUMMARY OF THE INVENTION 



INVENTION 



» « « , , , . 45 A method and apparatus are described for providing a 

A method and apparatus are described for providing a K ^ and maintainable atin tem in a nel . booled 

reliable and maintainable operating system in a net-booted environmenl . Broadl stated> embo d im6 nts of the present 

environment. According to one embodiment, a network ^ tQ ^ a fault . tolerant> ^.^tiag, and 

computer (NC) chent boots from a boot image provided by remote] mainlainable ati lem for me clients m , 

an NC server. The boot image includes information identi- 5Q net . booted environment . According to one embodiment of 

fying the location of one or more system volumes on the NC ^ , a Qetwork (NC) system 

server tha contain operating system software. In response to , of ^ ^ ^ ^ ^ be 

an attempt to modify the contents of the one or more system ted b Qrdi ^ ^ NC Additionally, 

volumes, the NC chent causes mformat.on identifying the (h<j NC ffl ma e user customizationSi such as 

mod.ficat.on to be recorded on the NC server separate from J5 fe b maintaining indivi^i, user> storag e areas. 

,h°?h °^ 0r f. SyStem V0lumeS m 8 S,0rage area associaled When an NC client boots from the network and accesses a 

with the NC client. s(ored CQpy Qf ^ operating system from ^ NC xrV fx, the 

Other features and advantages of the invention will be user > s preferences are dynamically merged with the system 

apparent from the accompanying drawings and from the environment provided to the NC chent. Advantageously, 

detailed description. 60 s i ncei me user's desktop preferences and other customized 

BRIEF DESCRIPTION OF THE SEVERAL T *" P reseived fr ° m session to session and sup- 

VIEWS OF THE DRAWINGS phed , l ° the NC che °' 85 ,? bo0tS tl ° m the n <; tw ° r > toe user 

may login to any NC chent on the network and have the 

The present invention is illustrated by way of example, same user experience. According to another embodiment, a 

and not by way of limitation, in the figures of the accom- 65 network administrator can upgrade every NC client in the 

panying drawings and in which like reference numerals refer NC system to a new version of the operating system by 

to similar elements and in which: simply replacing a single file on the NC server. Further, 
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according to another feature of the present invention, the 
network administrator can perform such an upgrade 
remotely from any NC client of the NC system. 
Advantageously, in this manner, NC system administration 
and maintenance costs are kept low as compared to a typical 5 
network of thick clients that each has a local copy of the 
operating system that must be replaced. 

In the following description, for the purposes of 
explanation, numerous specific details are set forth in order 
to provide a thorough understanding of the present inven- 1Q 
tion. It will be apparent, however, to one skilled in the art 
that the present invention may be practiced without some of 
these specific details. In other instances, well-known struc- 
tures and devices are shown in block diagram form. 

The present invention includes various steps, which will 
be described below. The steps of the present invention may 1 
be performed by hardware components or may be embodied 
in machine-executable instructions, which may be used to 
cause a general-purpose or special-purpose processor or 
logic circuits programmed with the instructions to perform 
the steps. Alternatively, the steps may be performed by a 20 
combination of hardware and software. 

The present invention may be provided as a computer 
program product which may include a machine-readable 
medium having stored thereon instructions which may be 
used to program a computer (or other electronic devices) to 25 
perform a process according to the present invention. The 
machine-readable medium may include, but is not limited to, 
floppy diskettes, optical disks, CD-ROMs, and magneto- 
optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnet 
or optical cards, flash memory, or other type of media/ 30 
machine-readable medium suitable for storing electronic 
instructions. Moreover, the present invention may also be 
downloaded as a computer program product, wherein the 
program may be transferred from a remote computer (e.g., 
a server) to a requesting computer (e.g., a client) by way of 35 
data signals embodied in a carrier wave or other propagation 
medium via a communication link (e.g., a modem or net- 
work connection). Accordingly, herein, a carrier wave shall 
be regarded as comprising a machine- readable medium. 

Importantly, while embodiments of the present invention 40 
will be described with reference to the Mac® operating 
system (OS) software and NetBoot technology on a Mac OS 
X Server, the method and apparatus described herein are 
equally applicable to other types of servers and operating 
systems, such as Microsoft® Windows® 95/98, Windows 45 
NT, Windows 2000, Windows CE, AIX, UNIX®, Linux, and 
the like. Consequently, the techniques described herein are 
thought to be generally useful in connection with remote 
bootstrapping of client systems in a variety of operating 
environments and networking environments. 50 
Terminology 

Before describing an exemplary environment in which 
various embodiments of the present invention may be 
implemented, some terms that will be used throughout this 
application will briefly be defined. 55 

The terms "boot," "booting," "bootstrap," and "bootstrap- 
ping" generally refer to the process of starting-up a 
computer, which typically involves loading operating sys- 
tem software. 

An "image" refers to an electronic representation of an 60 
individual disk or a portion thereof. 

The term "file system" generally refers to the logical 
structures and software routines used to control access to 
and from the storage on a storage medium, such as a hard 
disk system. 65 

An "operating system" refers to a program that manages 
a computer's internal functions and provides a means to 
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control the computer's operations and file system. Examples 
of operating systems include: MacOS, Windows 95/98, 
Windows NT, Windows 2000, Windows CE, AIX, UNIX, 
and Linux. "Personal compute r" generally refers to a com- 
puter system equipped with system, utility, application 
software, and/or input/output devices. Importantly, as used 
herein, the term "personal computer" is intended to refer 
collectively and individually to stand-alone Macintosh ® 
computers, Apple® computers, IBM® Personal Computers, 
IBM PC compatible computers, Amiga computers, and 
others, such as Commodore that are no longer manufactured 
and those yet to be manufactured. 

The term "thick client" generally refers to a computer 
system, such as a personal computer (PQ, that includes a 
hard drive or other local storage medium. Traditionally, such 
computer systems boot and execute application programs 
from the local storage medium. 

A "thin client" generally refers to a disk- less computer 
system that relies upon external means, such as a server, to 
supply it with an operating system and application pro- 
grams. 

As used herein, the terras "network computer client" or 
"NC client" generally refer to a client (thick or thin) that 
boots by accessing a copy of the operating system over a 
network. As such, an NC client is not required to be 
disk-less. 

The terms "network computer server** or "NC server" 
generally refer to a computer system that services requests 
of NC clients. For example, an NC server may provide 
access to a copy of the operating system to an NC client in 
response to a boot request. 

A "network computer system" or "NC system" refers to a 
network including one or more NC clients and one or more 
NC servers. 

In the context of this application, the term "volume" 
generally refers to a fixed amount of storage on a storage 
medium, such as a disk or tape. In some instances, however, 
the term may be used as a synonym for the storage medium 
itself. However, it is possible for a single storage medium to 
contain more than one volume or for a volume to span more 
than one storage medium. 
Network Computer System Overview 

In order to obtain the benefits of low-cost administration, 
all storage of application programs and operating system 
software for an NC system is preferably on the NC server. 
This doesn't mean the NC clients have no mass storage, but 
rather that the NC clients boot over the network by accessing 
a stored copy of the operating system from the NC server. 
Additionally, when NC clients want to run an application, 
they access it from the NC server. Advantageously, in this 
manner, an application may be upgraded by simply replac- 
ing the old version of the application with a new version on 
the NC server. Then, the next time an NC client requests the 
application, the NC client will receive the new version. 

FIG. 1 is a simplified block diagram that conceptually 
illustrates an NC system 100 according to one embodiment 
of the present invention. In this example, the NC system 100 
includes an NC client 150 coupled to an NC server 170 via 
a data communication link 140, such as a 10, 100, or 1000 
megabit/second Ethernet link. While according to one 
embodiment, the NC client 150 is a Macintosh computer or 
iMac™ computer and the NC server 170 is a Mac OS X 
Server, the NC client 150 and/or the NC server 170 may 
alternatively represent one or a combination of the devices/ 
systems described below with reference to FIG. 2. 

The NC server 170 includes one or more system volumes 
174, one or more application volumes 176, a user registry 
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178, non-persistent client-specific data 184, and persistent by simply replacing the system and/or application volumes 

user data 186. The system volumes 174 include a protected, on the NC server with the modified file, 

read-only, master copy of the operating system software. In one embodiment the server software management 

The application volumes 176 include copies of various process 180 manages access to and from the non-persistent 

application programs for use by the NC client 150. Accord- 5 client-specific data 184. For example, at the conclusion of a 

ing to one embodiment, the user registry 178 is a database user session on an NC client, the server software manage - 

of authorized users, user passwords, NC client hardware ment process 180 may provide data that is to be preserved 

addresses, such as Ethernet Media Access Control (MAC) between user sessions to the user environment management 

addresses, and NC client network addresses, such as Internet process 182 and reinitialize the client-specific storage area 

Protocol (IP) addresses. In an AppleTalk network environ- 30 associated with the NC client for use by the next user, 

ment or the like, the user registry 178 may comprise the According to one embodiment, the server software manage- 

AppleShare Registry. The non-persistent client-specific data ment process 180 performs self -repair functionality at two 

184 represents temporary data storage that is typically levels, automatic and administrator commanded. For 

preserved only for the duration of a user session on a example, the NC server 170 may be configured to automati- 

particular NC client. The persistent user data 186 represents 15 cally replace the shadow volume at every boot of a NC client 

long-term data storage for user information that is desirable 150. This insures that every time that NC client boots it will 

to retain between user sessions, such as preferences, browser have a complete, functional operating system regardless of 

bookmarks, and other desktop environment custom izations. any changes any connected user has made to their system. In 

The NC server 170 also includes a boot server process the event that a user performs some action which would 

172, a server software management process 180, and a user 20 damage their operating system in a standard desktop 

environment process 182, each of which may include hard- environment, the server software management process 180 

wired circuitry or machine -executable instructions or a repairs that damage at the next boot, 

combination thereof. Furthermore, at least a portion of such According to one embodiment, the user environment 

hard -wired circuitry and/or machine -executable instructions management process 182 tracks and maintains the persistent 

may be shared between a combination of the boot server 25 user data 186 to insure that changes the user has made during 

process 172, the server software management process 180, the current session will be persistent at the next logic. For 

and the user environment process 182. In one embodiment, example, upon termination of a user session, preferences, 

at least one storage area/memory (e.g., a machine-readable desktop items, and various other information representing 

medium) having appropriate routines and/or data stored changes made by the user during the user session are copies 

therein coupled to at least one processor is utilized, at least 30 to a user-specific storage location on the NC server 170. 

in part, to implement one or a combination of the boot server Subsequently, at the user's next login, from the same or 

process 172, the server software management process 180, different NC client, the user environment management pro- 

and the user environment process 182. cess 182 will retrieve the data from the corresponding 

According to one embodiment, the boot server process user-specific storage location and return it to the NC client 

172 manages access to and from the system volumes 174 35 thereby allowing the user to login to any NC client of the NC 

and the application volumes 176. Additionally, the boot system 100 and have the same user experience, 

server process 172 per forms server-side bootstrapping In one embodiment, the administration tool 188 facilitates 

processing. In one embodiment, the boot server process 172 NC system administration by automating certain file 

may include conventional Bootstrap Protocol (Bootp) server manipulations that are common for software installation and 

processing that waits for NC. clients to appear on the 40 configuration changes. The administration tool 188 is 

network in accordance with Request For Comments (RFC) described further below. 

951, Bill Croft, John Gilmore, Bootstrap Protocol, RFC 951, While for purposes of illustration, the boot server process 
September 1985, RFC 2132, and uses the standard exten- 172, the server software management process 180, the user 
sions format. As described further below, when the boot environment process 182, and the administration tool 188 
server process 172 receives a boot request from the NC 45 are shown as part of a single NC server 170, in alternative 
client 150, the boot server process 172 may provide the NC embodiments, they may be distributed in whole or in part 
client 150 with a network address, such as an Internet across multiple server computer systems. Additionally, the 
Protocol (IP) address, the address of the NC server 170, and system volumes 174, the application volumes 176, the user 
the name of a file to be loaded into memory and executed. registry 178, the non-persistent client-specific data 184, and 
This first phase of the bootstrapping process is described by 50 the persistent user data 186 may be independently distrib- 
RFC 951 as the "address determination and bootfile selec- uted across multiple server computer systems, 
tion" phase. The second phase of the boot strapping process The NC client 150 includes one or more system volume 
involves the file transfer of the bootfile (also referred to as images 160 and one or more application volume images 162. 
a boot image) by way of the Trivial File Transfer Protocol The outlines of the system volume images 160 and the 
(TFTP), the Simple File Transfer Protocol (SKIP), the File 55 application volume images 162 are shown with dotted 
Transfer Protocol (FTP), or the like. Further details regard- outlines because preferably only representations of the con- 
ing the particular information exchanged during these two tent of the corresponding NC server volumes are stored in 
phases will be described below. random access memory of the NC client 150 rather than 
In one embodiment, to facilitate remote NC system copies of the actual underlying data and files of the corre- 
administration, such as the installation of new system or 60 sponding NC server volumes. 

application software, the boot server process 172 may serve The NC client also includes a file system 152, a block 
application and system images that exist in the NC client's device driver 154, a network stack 156, and a network 
folder at the time of bootstrapping as a read write file. In this device driver 158, each of which may include hard-wired 
manner, a user having proper access privileges on the NC circuitry or machine-executable instructions or a combina- 
system, such as an NC system administrator, may create a 65 tion thereof. Furthermore, at least a portion of such hard- 
read-write file from any NC client in the NC system, modify wired circuitry and/or machine-executable instructions may 
the read -write file, and subsequently upgrade the NC system be shared between a combination of the file system 152, the 
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block device driver 154, the network stack 156, and the 
network device driver 158. In one embodiment, at least one 
storage area/memory (e.g., a machine-readable medium) 
having appropriate routines and/or data stored therein 
coupled to at least one processor is utilized, at least in part, 5 
to implement one or a combination of the file system 152, 
the block device driver 154, the network stack 156, and the 
network device driver 158. 

The file system 152 represents logical structures and 
software routines that are used to control access to and from 10 
a local storage medium, such as a hard disk system. Since 
the NC client 150 may not have a local mass storage device, 
the file system 152 may actually control access to and from 
a remote storage medium with or without knowledge that 
this is occurring. According to one embodiment, the file 15 
system 152 operates as if the contents of the system volumes 
160 are, in fact, contained on a local hard drive and the file 
system's read and write requests are redirected at a lower 
level of the operating system. In an alternative embodiment, 
the file system 152 itself may be given knowledge regarding 20 
the need to read and write to the network rather than to a 
local hard drive. 

The block device driver 154 services file system read and 
write requests to the system volumes 160. In one 
embodiment, the block device driver 154 appears to the file 25 
system 152 to be a standard hard drive device driver. 
However, in reality, the block device driver 154 may be 
configured to service the read and write requests of the file 
system 152 by accessing the NC server 170. As will be 
discussed further below, in one embodiment, one or more 30 
shadow volumes, may be created for the NC client 150 and 
stored with the non-persistent client-specific data 184 for the 
purpose of storing user preferences and/or changes to the 
operating system. Therefore, some mechanism is needed to 
direct reads and writes to the appropriate volume, e.g., the 35 
shadow volumes or the system volumes 174. According to 
one embodiment, the block device driver 154 has knowledge 
of the separate shadow volumes and system volumes 174 
and redirects read and write requests to the appropriate 
volume. Alternatively, server-side logic may perform the 40 
redirection locally. 

The network stack 156 represents logical structures and 
software routines that are used to control access to and from 
the data communication link 140. In this example, the 
network stack 156 employs the services of the network 45 
device driver 158 to transform data into electrical signals 
that are appropriate for the specific type of physical media, 
such as Ethernet. 

Exemplary Digital Processing System 

FIG. 2 is a block diagram of a digital processing system 50 
which may be used in accordance with one embodiment of 
the present invention. For example, the digital processing 
system 200 shown in FIG. 2 may be used as an NC client, 
an NC server, or other server computer system, such as an 
NT server. The digital processing system 200 may be 55 
interfaced to external systems through a network interface 
268. It will be appreciated that the network interface 268 
may be considered as part of the digital processing system 
200. The network interface 268 may be an analog modem, 
an ISDN modem, a cable modem, a token ring interface, a 60 
satellite transmission interface, a wireless interface, or other 
interface(s) for providing a data communication link 
between two or more digital processing systems. 

The digital processing system 200 includes a processor 
252, which may represent one or more processors and may 65 
include one or more conventional types of such processors, 
such as Motorola PowerPC processor, an Intel Pentium (or 
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x86) processor, etc. A memory 254 is coupled to the pro- 
cessor 252 by a bus 256. The memory 254 may be a dynamic 
random access memory (DRAM) and/or may include static 
RAM (SRAM). The processor may also be coupled to other 
types of storage areas/memories (e.g., cache, Flash memory, 
disk, etc.), which could be considered as part of the memory 
254 or separate from the memory 254. 

The bus 256 further couples the processor 252 to a display 
controller 258, an optional mass memory 262, the network 
interface 268, and an input/output (I/O) controller 264. The 
mass memory 262 may represent a magnetic, optical, 
magnetooptical, tape, and/or other type of machine-readable 
medium/device for storing information. For example, the 
mass memory 262 may represent a hard disk, a read-only or 
writeable optical CD, etc. The display controller 258 con- 
trols in a conventional manner a display 260, which may 
represent a cathode ray tube (CRT) display, a liquid crystal 
display (LCD), a plasma display, or other type of display 
device. The I/O controller 264 controls I/O device(s) 266, 
which may include one or more keyboards, mouse/trackball 
or other pointing devices, magnetic and/or optical disk 
drives, printers, scanners, digital cameras, microphones, etc. 

It will be appreciated that the digital processing system 
200 represents only one example of a system, which may 
have many different configurations and architectures, and 
which may be employed with the present invention. For 
example, Macintosh and Intel systems often have multiple 
busses, such as a peripheral bus, a dedicated cache bus, etc. 
On the other hand, a network computer, which may be used 
as a digital processing device of the present invention, may 
not include, for example, a hard disk or other mass storage 
device, but may receive routines and/or data from a network 
connection, such as the network interface 268, to be pro- 
cessed by the processor 252. Similarly, a Web TV system, 
which is known in the art, may be considered to be a digital 
processing system of the present invention, but such a 
system may not include one or more I/O devices, such as 
those described above with reference to I/O device(s) 266. 
Additionally, a portable communication and data processing 
system, which may employ a cellular telephone and/or 
paging capabilities, may be considered a digital processing 
system which may be used with the present invention. 

The processor 252 may execute one or more routines to 
redirect read and write requests from the file system 152 of 
the NC client to an appropriate volume on the NC server. 
Such routines may be stored in the mass memory 262, the 
memory 264, and/or another machine-readable medium 
accessible by the digital processing system 200. According 
to one embodiment of the present invention, a network 
computer (NC) system maintains a copy of the operating 
system in the mass memory 262 (and/or the memory 254) 
that cannot be corrupted by ordinary users of the NC system. 
Additionally, the NC system may preserve user 
customizations, such as preferences, by maintaining 
individual, user, storage areas in the mass memory 262 
(and/or the memory 254). When an NC client boots from the 
network and accesses the operating system from an NC 
server, the user's preferences are dynamically merged with 
the system environment provided to the NC client. 
Advantageously, since, the user's desktop preferences and 
other customized settings are all preserved from session to 
session and supplied to the NC client as it boots from the 
network, the user may login to any NC client on the network 
and have the same user experience. According to another 
embodiment, a network administrator can upgrade every NC 
client in the NC system to a new version of the operating 
system by simply replacing a single file on the NC server. 
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Further, according to another feature of the present 
invention, the network administrator can perform such an 
upgrade remotely from any NC client of the NC system. 
Advantageously, in this manner, NC system administration 
and maintenance costs are kept low as compared to a typical 5 
network of thick clients that each has a local copy of the 
operating system that must be replaced. 
Net-booting Overview 

Having briefly described an exemplary environment in 
which the present invention may be employed, exemplary 
net -boot processing will now be described with reference to 
FIG. 3. Providing a reliable, fault-tolerant and maintainable 
operating system for all NC clients in a net-booted environ- 
ment is an important component in insuring the successful 
implementation of such as system. NC clients have no 
operating system internally. Therefore, they depend on reli- 35 
ably retrieving a complete operating system from the net- 
work to boot and continue operations. 

The NC system environment and the net-booting process 
described herein are intended to provide the needed reliabil- 
ity. The net-booting process generally breaks down into an 20 
address determination and bootfile selection phase, a file 
transfer phase, a RAM boot phase and a system boot. The 
address determination and bootfile selection phase is repre- 
sented by steps 350 through 375, the file transfer phase 
includes steps 380 and 385, and the RAM boot phase is 25 
represented by steps 390 and 395. Briefly, for administrative 
and maintenance purposes, preferably only the NC server 
320 has a copy of the master read-only operating system 
image and NC clients boot according to the net-booting 
process described below. Since rebooting an NC client 30 
restores the NC client to a standard, useable state, it is 
impossible for a user without proper access privileges to 
make an NC client unbootable. Consequently, this NC 
system architecture and net-booting approach greatly sim- 
plifies NC client administration and provides a high level of 35 
reliability for the NC clients. 

The first phase of the net-booting processing begins at 
step 350. After the NC client 310 has powered on, the NC 
client 310 starts the address determination and bootfile 
selection phase by initiating the boot process out of a local 40 
read-only memory (ROM). This may include executing 
power-on self tests, acquiring device information, and per- 
forming any other functions necessary to give the NC client 
310 a basic identify. 

At step 355, the NC client 310 connects to the network 45 
and asks for additional information to be provided to it that 
will allow it to boot further. According to one embodiment, 
the request for additional information takes the form of a 
Bootp request. In alternative embodiments, the Dynamic 
Host Configuration Protocol (DHCP) may be employed. 50 

At step 360, the NC server 320 receives the boot request 
and determines if the request is from a known NC client. For 
example, the NC server 320 may search the user registry 178 
for the NC client's hardware address. 

If the NC client 310 is unknown to the NC server 320, 55 
then an IP address is allocated for the NC client 310 at step 
370 and registration processing is performed. In order to 
allow the NC server 320 to recognize the NC client 310 next 
time it boots, information regarding the NC client 310 may 
be stored in the user registry 178. For example, the NC 60 
client's hardware address can be marked as known in the 
user registry 178 and the IP address allocated can be 
associated in the user registry with the NC client's hardware 
address. User registration processing may include creating a 
user for this NC client 310, e.g., by adding the user to the 65 
user registry 178, and creating a private system file for the 
user. 
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If the NC client 310 is known to the NC server 320, then 
at step 365 information regarding the NC client 310, such as 
its IP address may be retrieved from the user registry 178. 

At step 375, boot information is returned to the NC client 
310. The boot information may include, among other things, 
the IP address of the NC client 310, the IP address of the NC 
server 320, the name of the file to be loaded into the NC 
client's memory and executed, and the names and locations 
of shadow volumes, if any. 

The second phase of the bootstrapping process, file trans- 
fer of the bootfile, begins at step 380. According to one 
embodiment, the NC client 310 sends a file transfer request 
to the NC server 320 specifying the bootfile identified in the 
NC server's Bootp reply. At step 385, the NC server 320 
responds by initiating the transfer of the boot image. Upon 
receipt at the NC client 310, the boot image is stored in a 
local RAM of the NC client 310. 

After the NC client 310 has received the boot image from 
the NC server 320, the RAM boot phase begins at step 390. 
During the RAM boot phase, the NC client 310 begins to 
execute the boot image out of the local RAM. According to 
one embodiment, the boot image is a Macintosh ROM image 
that performs additional machine initialization, and creates 
a Macintosh environment. In alternative embodiments, the 
boot image may create other operating environments, such 
as Windows 95/98, Windows NT, Windows 2000, etc. In one 
embodiment, the block device driver 154 may be included as 
part of the boot image. Alternatively, the block device driver 
154 may be part of the NC client's ROM. 

Finally, at step 395, the NC client 310 mounts the remote 
system and application volumes 174 and 176. Other boot 
processing (not shown) may include a system boot phase in 
which the setting up of the operating environment is com- 
pleted and the virtual memory subsystem is initialized. At 
this point, a login may be presented on the NC client 310. 
Based upon the user information, the user environment 
management process 182 may move all the components that 
are specific to this user, including preferences, to the user's 
system environment. 
System Read/Write Redirection 

As indicated above, the NC client 150 may or may not 
have a local storage medium, such as a hard disk system. 
Therefore, in one embodiment, the block device driver 154 
may redirect read and write requests received from the file 
system 152 to a remote storage medium on the NC server 
170, for example. 

FIG. 4 is a flow diagram illustrating how NC client write 
requests directed to the system volumes 160 are handled 
according to one embodiment of the present invention. In 
one embodiment, the steps described below may be per- 
formed under the control of a programmed processor, such 
as processor 252. However, in alternative embodiments, the 
steps may be fully or partially implemented by any pro- 
grammable or hardcoded logic, such as Field Programmable 
Gate Arrays (FPGAs), TTL logic, or Application Specific 
Integrated Circuits (ASICs), for example. 

According to the embodiment depicted, at step 410, the 
file system 152 generates a write request directed to the 
system volumes 160. The write request is received by the 
block device driver 154 and redirected by the block device 
driver 154 at step 420 by translating it into a write request 
directed to the user's shadow volume on the NC server 170. 
At step 430, the NC server 170 stores information associated 
with the write request in the shadow volume associated with 
the NC client 150. In this manner, the file system 152 need 
not be aware that attempted modifications to the system 
volumes 160 are recorded instead in a client-specific shadow 
volume residing on the NC server 170. 
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In alternative embodiments, however, the file system 152 In yet another embodiment, the NC server 170 may 

may be configured to recognize that write requests should be maintain separate copies of the operating system in its 

directed to the network interface 268. In these embodiments, entirety for each user, including any user-specific modifica- 

the file system 152 may be configured to bypass the block tions. In this case, neither the block device driver 154 nor the 

device driver and interface directly with the network stack 5 NC server 170 would need to track which portion(s) of the 

156. operating system contain user modifications. Rather, the 

In other embodiments, the block device driver 154 may portion of the user-specific copy of the operating system 

retain knowledge that writes are to be redirected to the NC corresponding to the read request may simply be returned in 

server 170, but may not be aware of the existence of the response to the read request, 

shadow volume. Therefore, the block device driver 154 will to Exemplary Server Directory Structure 

issue write requests to the NC server 170, but will issue these FIG. 6 is a simplified block diagram illustrating the layout 

requests to the system volumes 174 rather than the shadow of an exemplary hierarchical directory structure that may be 

volume. In this situation, logic on the NC server 170 will used by an NC server according to one embodiment of the 

redirect the write requests received from the NC client 150 present invention. 

to the appropriate shadow volume. 15 According to the embodiment depicted, a hard drive 610 

According to yet another alternative embodiment, the NC of the NC server 170 or other mass storage device associated 

server 170 may maintain separate copies of the operating with the NC server 170 includes an NC folder (directory) 

system software in its entirety for each user. However, this 620. Within the NC folder 620 are an NC admin folder 630 

would likely have the effect of increasing complexity of the and an NC shared data folder 640. The NC admin folder 630 

NC server 170 and could potentially dramatically increase 20 is preferably inaccessible to ordinary users that do not have 

the storage requirements of the NC server 170. proper access privileges and includes a read-only, master 

Referring now to FIG. 5, NC client read request process- operating system image 650. 

ing will now be described according to one embodiment of The NC shared data folder 640 includes a shared operat- 

the present invention. In one embodiment, the steps ing system image 660, a boot image 670, and a clients folder 

described below may be performed under the control of a 25 680. The shared operating system image 660 is a read-write 

programmed processor, such as processor 252. However, in version of the read-only master operating system image 650 

alternative embodiments, the steps may be fully or partially and may be mounted by the NC client 150 as part of step 

implemented by any programmable or hardcoded logic, such 395. The boot image 670 is downloaded and executed by the 

as Field Programmable Gate Arrays (FPGAs), TTL logic, or NC client 150 after the first phase of the bootstrapping 

Application Specific Integrated Circuits (ASICs), for 30 process in order to create an operating environment on the 

example. NC client 150, such as a Macintosh or Windows environ - 

In the embodiment depicted, it is assumed that the shadow ment. 

volume contains only those portions of the operating system The clients folder 680 is an area that may be used to store 

that have been modified by the user rather than a complete non-persistent client-specific information, such as modifi- 

copy of the operating system as modified. The various 35 cations to the shared operating system 660. In this example, 

options regarding the granularity of the portions written to the NC clients are numbered from I to N and the clients 

the shadow volume are discussed below. folder 680 includes a folder for each NC client. For example, 

At any rate, according the present example, at step 510, an NC #folder 690 is an area for storing client-specific 

the file system 152 generates a read request directed to the information, such as a shadow image 695, corresponding to 

system volumes 160. At step 520, the read request is 40 NC client #1. As described above, the shadow image 695 

received by the block device driver 154 and a determination preferably contains only portions of the shared operating 

is made whether the read request specifies a portion of the system image 660 that have been modified by the user, 

operating system that has been modified by the user or However, the shadow image 695 may be a user-specific copy 

whether the read request specifies a portion of the operating of the shared operating image 660 in its entirety, 

system that remains unchanged. If the read request corre- 45 Network Computer System Administration 

sponds to a portion of the operating system that has not been As described above, according to one embodiment, NC 

modified by the user, the processing continues with step 530. system administration is facilitated by a feature of the boot 

However, if the read request corresponds to a portion of the server process 172 that serves application and system 

operating system that has been previously modified by the images to the NC client 150 as a read-write file if such 

user, then processing continues with step 540. 50 images exist in the NC client's folder. Thus, a user of the NC 

At step 530, the block device driver directs the NC server client 150 having proper access privileges is provided with 

170 to retrieve the information associated with the read the ability to upgrade the NC system by replacing the 

request from the system volumes 174. existing images being served to the NC clients with modified 

At step 540, the block device driver directs the NC server versions containing, for example, new system or application 

170 to retrieve the information associated with the read 55 software or configuration changes. 

request from the user's shadow volume. FIG. 7 is a flow diagram illustrating NC system admin- 

In this manner, the file system 152 need not be aware of istration processing according to one embodiment of the 

the particular mechanism used to coordinate user modifica- present invention. According to this example, at step 710, 

tions with the original operating system as contained in the the NC server 170 receives an administrator logic request 

system volumes 174. 60 from the NC client 150. At step 720, the NC server 170 

In alternative embodiments, rather than having the block performs administrator login processing to verify the user 

device driver 154 keep track of which portions of the has appropriate access privileges on the NC system 100. 

operating system that have been modified by the user, such Assuming the user has appropriate access privileges, pro- 

a tracking mechanism may be implemented centrally on the cessing continues with step 730. At step 730, one or more 

NC server 170. In this case, the NC server 170 would make 65 shared images (e.g., shared operating system image 660 

the determination of step 520 and provide the appropriate and/or a shared application image) are copied to the NC 

read responses in steps 530 and 540. client's folder on the NC server 170. At step 740, editing of 
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the one or more shared image copies (the working copies) is 
enabled. According to one embodiment, this is accomplished 
by simply rebooting the NC client 150 as discussed above. 
Alternatively, the attributes associated with the working 
copies may be modified in some other manner so as to make 5 
them editable by the user. In any event, at step 750, the user 
may add software and/or make configuration changes to the 
working copies. Finally, the NC system is updated at step 
760 by replacing the one or more shared images currently 
being served to NC clients with the working copies. 30 
Advantageously, in this manner, there is no need to log users 
out to insure that changes have been propagated across all 
the images. Instead, changes become accessible to a NC 
client the next time that NC client is booted thereby allowing 
all connected users to easily complete whatever tasks they 15 
are working on without impeding NC system administration. 

According to one embodiment, steps 730, 740, and 760 
may be provided as part of the administration tool 188. The 
first execution of the administration tool 188 may accom- 
plish step 730 by copying the shared images to the appro- 20 
priate NC client folder. After the copies are complete, the 
administration tool 188 may automatically restart the NC 
client 150, which will boot up with read-write access to the 
working copies. 

At this point, the network administrator is free to add 25 
software and/or make configuration changes. When the 
network administrator has completed his/her changes, the 
administration tool 188 can be run for a second time at 
which point the network administrator may be presented 
with the option of either committing (saving) or discarding 30 
the changes to the working copies. If the administrator 
chooses to discard the changes, the administration tool 188 
marks the working copies for deletion. Note that immediate 
deletion of the working copies is not desirable because the 
NC client 150 is still using the working copies. Rather, it is 35 
preferable to remove the working copies that are marked for 
deletion during a subsequent boot of the NC client 150. In 
one embodiment, the administration tool 188 automatically 
restarts the NC client 150 thereby causing the removal of the 
working copies and causing the NC client 150 to boot from 40 
the shared images. 

If the administrator chooses to commit the changes, the 
administration tool 188 can immediately replace the shared 
images with those of the working copies that have been 
edited which makes the updates immediately available to 45 
any NC client that subsequently boots. 

Advantageously, the administration tool 188 allows the 
network administrator to remotely modify the shared images 
on the NC server 170 from an NC client without having to 
access the NC server 170 directly. Additionally, use of the 50 
administration tool 188 allows the administrator to update 
the NC system 100 without having to know about or directly 
manipulate the files on the NC server 170. 

FIG. 8 is a simplified block diagram illustrating two NC 
systems 810 and 820 coupled via the Internet 805. It is 55 
contemplated that the NC system configuration process 
described above with reference to FIG. 7 may also be useful 
in connection with the reconfiguration of remote NC sys- 
tems. For example, the administration tool 188 may be run 
from any of NC clients 812, 814, or 816 to install a new 60 
application program on local NC system 810 that is desired 
by the users of the local NC system 810 as well as by the 
users of NC clients 822, 824, and 826 of remote NC system 
820. After completing the steps described above for instal- 
lation on the local NC system 810, the administration tool 65 
188 running on NC system 810 may replicate the modified 
shared images to the remote NC system 820. 
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Split Operating System 

FIG. 9 is a block diagram that conceptually illustrates NC 
client interaction with a SplitOS 920 according to one 
embodiment of the present invention. According to the 
example depicted, the SplitOS 920 of the NC server 170 
contains a read-only core system volume image 922 and a 
read-write user system volume image 924. 

The core system volume 922 preferably contains those 
parts of the system that do not need to be written back to 
during system operation. One goal of the core system 
volume 922 is to provide all the system components that are 
mandatory for system operation. By separating these essen- 
tial components from the user system volume 924 and 
protecting them as read-only, an additional level of stability 
is provided to the NC system 100 since a user will be unable 
to delete or move items that are essential to system opera- 
tion. 

The user system volume 924 contains all the user- 
configurable system components, including preferences and 
all the system additions installed by application software, 
such as application-installed extensions and libraries. 
Additionally, the user system volume 924 may contain 
applications that cannot be run from an AppleShare server 
and/or other system components that do not function on a 
read-only volume. 

Preferably, the NC server 170 also creates a shadow 
system volume 930 for each connected NC client. The 
shadow system volume 930 shadows the user system vol- 
ume 924 by storing modifications that are made to the user 
system volume 924. In alternative embodiments, the NC 
server 170 may provide a separate user system volume 924 
for each connected NC client. 

As described above, according to one embodiment, the 
shadow system volume 930 is used by the block device 
driver 154 of the NC client 150 to implement a "copy-on- 
write" storage scheme in which modifications (writes) 
directed to the user system volume 930 are instead copied to 
the shadow system volume 930. In one embodiment, the 
shadow system volume 930 is not visible to the user. 
Consequently, the user system volume 924 will appear to be 
the location where all writes are directed. For example, if a 
user modifies a preference, that preference will appear to be 
written to the preference file located in the preferences 
folder on the user system volume 924. 

As indicated by the directional arrows along the connec- 
tions between the core system volume 922, the user system 
volume 924, and the shadow system volume 930 and the NC 
client 910, data may be read from each of the core system 
volume 922, the user system volume 924, and the shadow 
system volume 930; however, data may only be written to 
the shadow system volume 930. 
Shadow System Volume 

FIG. 10 is a block diagram that conceptually illustrates the 
structure of a shadow system volume 1020 according to one 
embodiment of the present invention. In this example, the 
shadow system volume 1020 is a complete copy of the 
system volume 1010 with any user-modifications incorpo- 
rated therein. Therefore, the disk space used by the shadow 
system volume 1020 will be approximately the same as that 
used by the system volume 1010. 
Banding 

FIG. 11 is a block diagram that conceptually illustrates the 
structure of a sparse shadow system volume 1120 according 
to another embodiment of the present invention in which a 
banding feature is employed. According to this embodiment, 
the sparse shadow system volume 1120 is written in band 
increments rather than as an entire file. A band is a prede- 
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termined number of blocks. For example, according to one 
embodiment bands are 128K (256 512-byte blocks). In 
alternative embodiments, the band size may be more or less. 
Using bands, the disk space used by the shadow volume 
1120 will consist only of the actual data written (in band 5 
increments). 

According to one embodiment of the banding feature, the 
inherent one-to-one block mapping in copy-on-write images 
may be replaced with a table or other data structure that 
maps a band of the primary file to a corresponding band in 
the shadow file. Logic may be included in the block device 
driver 154, for example, to break up requests into the largest 
contiguous chunks possible. In this manner, both reads and 
writes can span non-contiguous band boundaries. 

The main motivation for banding is to reduce disk space 
requirements of the NC client shadow system images. 15 
According to one embodiment, the reduction is achieved by 
only storing those bands which have actually been written 
to. An exemplary band table 1122 is a simple array allocated 
at initialization. Entries in the table are assigned BAND_ 
NONE until the corresponding band is written to, at which 20 
point the next available band in the shadow file is assigned. 
In order to encourage contiguous blocks on the NC server's 
file system, in one embodiment, if bands are allocated during 
a write, the shadow file size is increased to the appropriate 
number of bands before the write request is sent. 25 
Exemplary Machine-Readable Medium 

FIG. 12 is an example of a machine-readable medium 
1200 that may be accessed by a digital processing system, 
such as an NC client or an NC server, according to one 
embodiment of the present invention. Importantly, the actual 30 
memory that stores the elements shown in and described 
below with reference to FIG. 12 may comprise one or more 
disks (which may, for example be magnetic, optical, 
magneto-optical, etc.), the memory 254 and/or the mass 
memory 262 described above with reference to FIG. 2, or a 35 
combination thereof. Additionally, one or more of the ele- 
ments of the machine-readable medium 1200 may be stored 
at one digital processing system, such as an NC server, and 
downloaded or transmitted to another digital processing 
system, such as an NC client or another NC server. 40 
Furthermore, the elements described with reference to the 
machine-readable medium 1200 may, at some point in time, 
be stored in a non-volatile mass memory (e.g., a hard disk). 
Conversely, at other times, the elements of the machine- 
readable medium 1200 may be dispersed between different 45 
storage areas, such as DRAM, SRAM, disk, etc. 

According to one embodiment, the machine-readable 
medium 1200 is utilized, at least in part, to facilitate admin- 
istration and maintenance of system and/or application vol- 
umes of an NC system in accordance with one or more 50 
methods of the invention. For example, the machine- 
readable medium 1200 may be associated with an NC server 
and include one or more routines for performing bootstrap- 
ping as discussed with reference to FIG. 3 (the boot server 
program 1205), for performing system read and write pro- 55 
cessing as discussed with reference to FIGS. 4 and 5 (the 
block device driver 1230), and/or for performing remote 
administration of the NC system 100 as discussed with 
reference to FIG. 7 (the administration program). While the 
block device driver 1230 is show as being separate from the 60 
boot image 1210 in this example, the block device driver 
may be provided as part of the boot image 1210 in alterna- 
tive embodiments, server 

ALTERNATIVE EMBODIMENTS 65 

While the invention has been described with reference to 
specific embodiments and illustrative figures, those skilled 
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in the art will recognize that the invention is not limited to 
the embodiments or figures described. In particular, the 
invention can be practiced in several alternative embodi- 
ments that provide net-booting and remote administration of 
an NC system. 

Therefore, it should be understood that the method and 
apparatus of the invention can be practiced with modifica- 
tion and alteration within the spirit and scope of the 
appended claims. The description is thus to be regarded as 
illustrative instead of limiting on the invention. 

What is claimed is: 

1. A method comprising: 

a network computer (NC) client booting from a boot 
image provided by an NC server, the boot image 
including information identifying the location of one or 
more user system volumes on the NC server, the NC 
client locally executing the boot image and mounting 
the one or more system volumes, the one or more user 
system volumes containing operating system software; 
and 

in response to an attempt to modify the contents of the one 
or more user system volumes, the NC client causing 
information identifying a modification associated with 
the attempt to be recorded on the NC server separate 
from the one or more user system volumes in a shadow 
system volume associated with the NC client; wherein 
the one or more system volumes are presented to the 
NC client as a split operating system including a core 
operating system volume that can be read but not 
written by the NC client and the user operating 
system volume that can be read and/or written by the 
NC client, wherein the storage area associated with 
the NC client comprises the shadow volume corre- 
sponding to the user operating system volume, and 
wherein the NC client causing information identify- 
ing a modification associated with the attempt to be 
recorded comprises tracking modifications to the 
user operating system volume in the shadow volume. 

2. The method of claim 1, further comprising 
transmitting information identifying a user of the NC 

client to the NC server; 

receiving information identifying the user's desktop envi- 
ronment preferences from the NC server; and 

customizing a desktop environment of the NC client in 
accordance with the user's desktop environment pref- 
erences. 

3. The method of claim 1, further comprising, prior to the 
step of booting from a boot image provided by an NC server, 
(1) the NC client initiating a boot process by booting into a 
local memory of the NC client, (2) the NC client transmit- 
ting a boot request to the NC server, and (3) the NC client 
receiving the boot image from the NC server. 

4. A network computer (NC) client comprising: 

a bootstrapping means for booting from a boot image 
provided by an NC server, the boot image including 
information identifying the location of one or more user 
system volumes on the NC server, and locally execut- 
ing the boot image and mounting the one or more 
system volumes, the one or more user system volumes 
containing operating system software; and 

a redirecting means, responsive to an attempt to modify 
the contents of the one or more user system volumes, 
for causing information identifying a modification 
associated with the attempt to be recorded on the NC 
server separate from the one or more user system 
volumes in a shadow system volume associated with 
the NC client; wherein 
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the one or more system volumes are presented as a split 
operating system including a core operating system 
volume that can be read but not written by the NC 
client and the user operating system volume that can 
be read and/or written by the NC client, wherein the 5 
associated storage area comprises the shadow vol- 
ume corresponding to the user operating system 
volume, and wherein causing information identify- 
ing a modification associated with the attempt to be 
recorded comprises tracking modifications to the 
user operating system volume in the shadow volume. 

5. The NC client of claim 4, further comprising a banding 
means for incorporating the modification within one or more 
bands comprising a predetermined number of blocks. 

6. A method comprising: J5 
a network computer (NC) client booting from a boot 

image provided by an NC server, the boot image 
including information identifying the location of one or 
more user system volumes on the NC server, the NC 
client locally executing the boot image and mounting 20 
the one or more system volumes, the one or more user 
system volumes containing operating system software; 
and 

in response to a write request from a file system of the NC 
client that contains a modification to the one or more 2 s 
user system volumes, a block device driver of the NC 
client redirecting the write request and causing infor- 
mation identifying the modification to be recorded on 
the NC server in a shadow system volume associated 
with the NC client that is separate from the one or more 30 
user system volumes; wherein 
the one or more system volumes are presented to the 
NC client as a split operating system including a core 
operating system volume that can be read but not 
written by the NC client and the user operating 35 
system volume that can be read and/or written by the 
NC client, wherein the storage area associated with 
the NC client comprises the shadow volume corre- 
sponding to the user operating system volume, and 
wherein the NC client causing information identify- 40 
ing a modification associated with the attempt to be 
recorded comprises tracking modifications to the 
user operating system volume in the shadow volume. 

7. A method comprising: 

a network computer (NC) client booting from a boot 45 
image provided by an NC server, the boot image 
including information identifying the location of one or 
more user system volumes on the NC server, the NC 
client locally executing the boot image and mounting 
the one or more system volumes, the one or more user 50 
system volumes containing operating system software 
that has one or more customizable attributes; and 
in response to a change to an attribute of the one or more 
customizable attributes, the NC client causing infor- 
mation identifying the change to be recorded on the NC 55 
server in a shadow system volume associated with the 
NC client that is separate and distinct from the one or 
more user system volumes; wherein 
the one or more system volumes are presented to the 
NC client as a split operating system including a core 60 
operating system volume that can be read but not 
written by the NC client and the user operating 
system volume that can be read and/or written by the 
NC client, wherein the storage area associated with 
the NC client comprises the shadow volume corre- 65 
spending to the user operating system volume, and 
wherein the NC client causing information identify- 
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ing a modification associated with the attempt to be 
recorded comprises tracking modifications to the 
user system volume in the shadow volume. 

8. A method comprising: 

a network computer (NC) server providing a boot image 
to an NC client, the boot image including information 
identifying the location of one or more user system 
volumes on the NC server, the NC client locally execut- 
ing the boot image and mounting the one or more 
system volumes, the one or more user system volumes 
containing operating system software; 

presenting to the NC client, the one or more system 
volumes as a split operating system including a core 
operating system volume that can be read but not 
written by the NC client and the user operating system 
volume that can be read and/or written by the NC 
client, wherein the storage area associated with the NC 
client comprises the shadow volume corresponding to 
the user operating system volume, and wherein the NC 
client causing information identifying a modification 
associated with the attempt to be recorded comprises 
tracking modifications to the user operating system 
volume in the shadow volume; and 

in response to a write request from the NC client that 
contains a modification to the operating system 
software, the NC server recording information identi- 
fying the modification on the NC server in a shadow 
system volume associated with the NC client that is 
separate from the one or more user system volumes. 

9. The method of claim 8, further comprising: 
receiving information identifying the user of the NC 

client; and 

providing the NC client with information indicative of the 
user's desktop environment by accessing the persistent, 
user-specific storage area. 

10. A network computer (NC) server comprising: 

a boot server means for providing a boot image to an NC 
client, the boot image including information identifying 
the location of one or more user system volumes on the 
NC server, so that the NC client can locally execute the 
boot image and mount the one or more system volumes, 
the one or more user system volumes containing oper- 
ating system software; 

a presentation means for presenting to the NC client, the 
one or more system volumes as a split operating system 
including a core operating system volume that can be 
read but not written by the NC client and the user 
operating system volume that can be read and/or writ- 
ten by the NC client, wherein the storage area associ- 
ated with the NC client comprises the shadow volume 
corresponding to the user operating system volume, 
and wherein the NC client causing information identi- 
fying a modification associated with the attempt to be 
recorded comprises tracking modifications to the user 
operating system volume in the shadow volume; and 

a storage management means for recording information 
identifying a modification to the operating system 
software in a shadow system volume associated with 
the NC client that is separate from the one or more user 
system volumes, the storage management means opera- 
tive in response to a write request from the NC client 
that contains the modification. 

11. A machine -readable medium having stored thereon 
data representing sequences of instructions, the sequences of 
instructions which, when executed by a processor, cause the 
processor to perform the steps comprising: 
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providing a boot image to an NC client, the boot image 
including information identifying the location of one or 
more user system volumes on the NC server and set so 
that the NC client may locally execute the boot image 
and mount the one or more system volumes, the one or 5 
more user system volumes containing operating system 
software; 

presenting to the NC client, the one or more system 
volumes as a split operating system including a core 
operating system volume that can be read but not 10 
written by the NC client and the user operating system 
volume that can be read and/or written by the NC 
client, wherein the storage area associated with the NC 
client comprises the shadow volume corresponding to 
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the user operating system volume, and wherein the NC 
client causing information identifying a modification 
associated with the attempt to be recorded comprises 
tracking modifications to the user operating system 
volume in the shadow volume; and 
in response to a write request from the NC client that 
contains a modification to the operating system 
software, the NC server recording information identi- 
fying the modification on the NC server in a shadow 
system volume associated with the NC client that is 
separate from the one or more user system volumes. 

***** 
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